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1  a  ABSTRACT  (Mawrun  200  wocal 

The  Joint  Surveillance  System  Distributed  Tracker  ( JDT)  was  designed  by  Hughes 
Aircraft  Company  for  use  in  a  laboratory  environment  in  conjunction  with  Command  and 
Control  experiments  in  support  of  the  air  defense  initiative.  The  tracker  provides 
a  live  air  picture  for  integration  with  the  Air  Defense  Initiative  Simulation  for 
Command  and  Control  (ADISC2).  It  was  designed  to  accept  radar  inputs  from  up  to  ten 
(10)  Joint  Surveillance  System  (JSS)  radars.  The  raw  radar  data  is  preprocessed  and 
each  radar  report  is  "tagged"  with  a  radar  site  ID.  The  data  is  then  broadcast  over 
an  Ethernet  to  the  JDT  which  resides  on  a  SUN  4-260  workstation.  A  track  file  is  then 
automatically  established  for  each  of  the  ten  (10)  radar  sites  using  an  N  hit  out  of 
M  scan  approach.  A  master  track  store  is  then  established  through  the  correlation  of 
the  individual  trrek  files  providing  a  single  correlated  air  picture  for  the  ten  (ID) 
radar  sites. 

Automatic  track  initiation  is  performed  over  multiple  radar  scans.  A  one-plot  track 
is  formed  initially.  If  on  the  next  scan,  a  plot  is  correlated  with  a  one-plot  track, 
that  track  is  upgraded  to  a  tentative  track.  Should  subsequent  scans  correlate  with 
the  tentative  track,  the  track  is  upgraded  to  system  track  status  and  is  then 
eligible  for  display.  Tracks  can  also  be  manually  initiated  through  mouse  driven 
menu  interaction.  (see  reverse) 
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The  JDT  software  is  structured  as  four  (4)  processes  (radar  inputs,  tracking, 
track-to-track  correlation,  and  displays)  and  two  (2)  object  libraries 
(interprocess  communication,  and  track  telling).  This  separation  of 
functional  modules  allows  any  process  to  reside  remotely  and  communicate  with 
other  workstations  via  the  interprocess  communications  package.  This  allows 
distribution  of  functionality  among  several  workstations  on  the  network. 
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FINALTECHNICAL  REPORT 
JOINT  SURVEILLANCE  SYSTEM 
DISTRIBUTED  TRACKER  (JDT) 


1 .  SYSTEM  OVERVIEW 

1 . 1  The  purpose  of  the  JDT  system  is  to  accept  radar  plot  data  from  up  to  ten  Joint 
Surveillance  System  (JSS)  radars  and  perform  the  tracking  function  to  create 
an  integrated  air  picture  display  for  the  area  of  coverage  of  those  radars.  The 
system  will  automatically  generate  tracks  based  on  the  radar  data  using  an  (N) 
hit  out  of  (M)  scan  approach.  The  JDT  will  also  be  capable  of  communicating 
track  data  out  of  the  system  and  to  other  processes  running  concurrently  in  the 
system.  The  system  has  a  track  correlation  process  that  can  accept  track  data 
from  a  maximum  of  ten  tracking  processes  running  concurrently  in  the  system, 
resolve  track  data  resulting  from  reports  from  different  radars  on  the  same 
target,  and  produce  a  master  track  file.  Map  overlays  will  be  used  to  display 
information  and  the  Man-Machine  Interface  (MMI)  will  allow  for  keyboard 
entries  and  mouse  selections.  Track  control  keys  allow  for  manual  track 
initiation,  entry  of  track  tell  status,  and  selection  of  non-automatic  track  initiation 
(NAI)  zones.  In  addition,  an  interface  to  the  ADISC2  Testbed  is  provided. 

1 .2  The  JDT  system  is  designed  to  operate  in  one  or  more  SUN4  workstations 
under  the  UNIX  operating  system.  The  software  is  organized  into  six  CSCIs. 
These  CSCIs  are  composed  of  four  processes:  (1 )  Tracking,  (2)  Track  to  Track 
Correlation,  (3)  Display,  and  (4)  Radar  Inputs;  and  two  object  libraries:  (1) 
Interprocess  Communication  (IPC)  and  (2)Telling.  The  JDT  processes 
communicate  with  one  another  via  the  IPC  which  allows  them  to  operate  within 
a  single  workstation  as  well  as  to  be  distributed  into  multiple  workstations.  The 
development  work  was  performed  using  a  single  workstation;  however,  when 
the  system  was  installed  at  RADC,  the  display  process  was  separated  to 
operate  in  a  second  workstation  to  allow  a  larger  radar  load  to  be  handled  by 
the  tracking  process.  Figure  1 .2  illustrates  the  interrelationship  between  the 
JDT  processes.  The  IPC  has  been  left  out  to  simplify  the  figure.  Basically  the 
IPC  would  be  shown  as  the  interface  between  each  process  in  a  more  detailed 
drawing.  A  major  feature  of  the  JDT  design  is  the  capability  to  operate 
software  processes  in  multiple  workstations.  Note  the  duplication  of  the 
Tracking  process  to  provide  one  process  for  each  radar  feeding  the  system. 
This  supports  handling  each  radar  with  a  separate  workstation,  all  radars  with 
a  single  workstation,  or  any  combination  in  between.  This  gives  extreme 
configuration  flexibility  to  adjust  to  various  load  conditions. 
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JDT  SOFTWARE  FUNCTIONS 


FIGURE  1.2 


2.  JDT  SOFTWARE  FUNCTIONAL  DESCRIPTION 

2.1  JDT  Interprocess  Communication  (IPC)  is  the  routing  process  within  the  JDT 
system.  It  receives  all  messages  and  routes  them  to  their  proper  destination.  It 
also  provides  two  modules  that  other  processes  may  use  to  read  and  write 
messages  to  and  from  the  IPC.  The  IPC  is  the  key  to  providing  the  configuration 
flexibility  required  for  the  JDT  system.  The  IPC  routes  process  to  process 
messages  based  on  data  stored  in  the  configuration  and  startup  files.  This 
allows  the  processes  to  communicate  independent  of  the  allocation  of 
processes  among  the  available  workstations. 

2.2  The  Telling  library  provides  for  the  packing  and  unpacking  of  the  Track  Data 
Message  and  the  Change  Track  Number  Message.  Telling  is  a  library  of 
routines  used  to  accomplish  the  processing  of  messages.  The  Telling  library 
provides  a  common  message  format  for  transmission  between  the  Tracker  and 
Correlator  or  ADISC2.  This  common  message  format  is  the  JSS  Track  Data 
Message  format. 

2.3  The  Tracking  process  is  capable  of  generating  maintaining,  and  processing 
tracks  which  represent  the  position,  velocity,  and  status  of  aircraft.  A  system 
track  will  be  generated  by  a  specific  initiation  process  (automatic  or  manual) 
and  continues  to  exist  until  one  frame  (equivalent  to  scan  time  of  the  radar)  after 
completion  of  a  specific  drop  process.  System  track  data  is  eligible  for  display. 
The  system  track  capacity  for  each  tracking  process  is  300  tracks.  Up  to  ten 
tracking  processes  can  be  active  in  the  JDT  system  at  a  time  (one  for  each 
radar  interfaced  with  JDT). 

The  tracking  function  generates  the  track  number,  position,  velocity,  and  status 
of  aircraft  based  upon  automatic  processing  of  Surveillance  Radar  (SR)  and 
Secondary  Surveillance  Radar  (SSR)  data  received  from  radar  sites.  This 
information  is  known  collectively  as  track  information.  Tracking  is  performed 
through  the  following  processes:  manual  track  initiation;  automatic  initiation; 
and  automatic  correlation,  smoothing,  and  prediction. 

The  manual  track  initiation  is  primarily  an  operator  function.  It  is  performed  by 
the  operator  specifying  the  position  and  velocity  of  the  aircraft.  The  tracking 
process  then  initiates  the  track  based  on  this  data. 

The  automatic  initiation  process  is  performed  over  several  radar  scans.  It  is 
initiated  when  a  radar  return  is  received  which  fails  to  correlate  with  any  system 
or  non-system  track.  The  first  step  is  to  form  a  one-plot  track  (a  non-system 
track)  at  the  location  of  the  radar  return.  The  second  step  of  the  process  occurs 
approximately  one  scan  later  if  a  radar  return  correlates  with  the  existing  one- 
plot  track.  It  is  then  promoted  to  a  tentative  track  (also  a  non-system  track).  The 
tentative  track  will  eventually  be  promoted  to  a  system  track  if  it  continues  to 
correlate  with  radar  returns  on  successive  scans  of  the  radar.  The  maximum 
number  of  one-plot  and  tentative  tracks  is  500. 
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Automatic  correlation,  smoothing,  and  prediction  is  the  process  of  comparing 
radar  return  data  with  existing  track  data,  deciding  if  it  matches  the  track 
(correlation),  and  updating  the  track  based  on  the  radar  return  data  and  the 
history  of  the  track  (smoothing  and  prediction).  In  an  ideal  situation  and  where 
a  track  is  not  maneuvering,  one  would  expect  that  the  best  update  for  a  track 
would  be  to  use  the  radar  return  data  once  correlation  is  accomplished. 
However,  the  real  environment  involves  getting  noise  returns,  as  well  as  real 
returns,  and  missing  some  real  returns  so  there  is  never  a  certainty  that  a 
correlation  of  a  radar  return  with  a  track  really  means  they  represent  the  same 
aircraft.  Smoothing  is  a  function  which  addresses  this  uncertainty.  Basically 
smoothing  results  in  partially  believing  the  radar  return  and  partially  believing 
the  projected  track  position  and  velocity  based  on  track  history.  The  track  is 
updated  based  on  a  compromise  of  these  two  sets  of  data  by  a  software 
algorithm. 

Maneuvering  targets  present  a  special  situation.  Since  the  radar  return  data 
will  not  match  the  tracks  expected  data  based  on  history  when  the  aircraft  is 
maneuvering,  there  is  an  uncertainty  in  the  correlation.  It  may  represent 
correlation  of  a  maneuvering  aircraft  or  it  may  simply  be  the  result  of  correlation 
with  a  noise  return.  The  JDT  system  handles  this  situation  by  creating  a 
bifurcating  track  (another  non-system  track).  The  result  is  that  the  operator  sees 
the  system  track  at  the  workstation  continue  approximately  as  if  it  is  not 
maneuvering.  Meanwhile,  Tracking  is  following  the  possible  maneuver  with  the 
bifurcated  track  which  is  not  disolayed.  Over  a  predetermined  set  of  radar 
scans,  it  is  determined  which  path  (the  non-maneuvering  vs  the  maneuvering) 
appears  to  represent  the  actual  aircraft's  behavior.  The  bifurcation  is  then 
resolved  in  favor  of  the  track  with  the  best  correlation  history.  If  this  results  in 
believing  that  the  track  is  maneuvering,  the  system  track  will  appear  to  jump  as 
its  position  is  corrected  to  be  placed  on  the  maneuver  path. 

2.4  The  purpose  of  the  JDT  Track  to  Track  Correlation  process  is  to  automatically 
determine  if  new  track  data  received  from  one  of  the  Tracking  processes 
correlates  with  track  data  already  established  in  the  Master  track  file.  The 
process  considers  the  following  track  attributes  in  making  this  decision: 

-  Track  Number 

-  SIF  Data 

-  Track  Position  and  Velocity 

The  correlation  status  of  a  track  may  go  through  several  provisional  states 
before  a  firm  decision  is  made,  but  the  processing  results  in  one  of  two  possible 
decisions: 

-  The  track  is  a  single  track  ( the  track  is  reported  by  only  one  tracker) 

-  The  track  is  one  of  a  pair  of  tracks  (the  track  is  being  reported  by  two  or 
more  trackers) 
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If  it  is  determined  a  new  pair  has  been  formed,  then  a  change  track  number 
message  is  sent  to  the  tracker  which  sent  the  new  track  data.  This  process 
assures  that  all  trackers  use  the  same  track  number  for  an  individual  aircraft. 

2.5  The  Display  process  provides  the  man-machine  interface  (MMI)  to  the  operator. 
It  provides  for  display  of  dynamic  situation  data,  tracks  and  plots  as  well  as  the 
MMI  menus,  keyboard  control,  and  mouse  control.  The  display  process 
interfaces  with  the  SUN-resident  commercial  package  rim\Ro  to  provide  this 
functionality.  The  MMI  and  display  features  of  JDT  are  described  fully  in 
Chapter  5  and  Chapter  6  of  Development  Program  Manual  for  this  contract. 


2.6  The  purpose  of  the  Radar  Inputs  process  is  to  receive  radar  data  from  the  Radar 
Data  Interface  Unit  (RDIU)  and  from  the  ADISC2  Testbed.  This  radar  data  is 
then  buffered,  formatted,  and  transmitted  to  the  proper  tracker  once  per  second. 


3.0  FINAL  TEST  REPORT 


The  formal  JDT  system  testing  was  accomplished  by  running  five  Tracker 
Acceptance  Tests  (TATS).  These  tests  are  listed  together  with  synopsis  in 
Table  3.0.  The  tests  were  run  at  Hughes  GSG  in  Fullerton  as  part  of  the  JDT 
system  checkout,  and  all  detected  problems  were  corrected.  The  tests  were 
then  run  formally  at  RADC  and  were  witnessed  by  RADC  personnel  as  part  of 
the  formal  system  selloff. 

3. 1  Testing  at  GSG  -  The  original  test  plan  for  the  JDT  system  was  to  run  the 
acceptance  tests  with  both  simulated  data  and  with  recorded  live  data  to 
thoroughly  test  the  system  prior  to  shipping  to  RADC.  The  recorded  live  data 
was  obtained  from  RADC  and  was  input  to  the  SUN  workstation  via  the  RADC 
developed  RDIU.  During  the  contract  execution  ,  the  RDIU  had  a  failure  which 
RADC  was  unable  to  repair  at  the  contractor's  facility.  This  required  performing 
all  the  checkout  and  testing  of  the  JDT  system  at  GSG  with  simulated  data.  This 
limitation  resulted  in  comprehensive  functional  testing  but  under  limited  load 
conditions.  Consequently,  the  first  time  the  system  was  tested  under  realistic 
load  conditions  was  after  installation  at  RADC  and  with  live  radar  data. 

3.2  Testing  at  RADC  -  Testing  began  at  RADC  in  early  October  1989.  Initial 
installation,  checkout,  and  testing  with  simulated  data  went  well  with  JDT 
passing  all  these  tests  as  it  had  in  Fullerton,  however,  testing  under  full  load 
conditions  revealed,  as  expected,  some  system  limitations.  First  the  system 
could  not  handle  a  full  load  from  six  radars.  This  was  due  partially  because  the 
commercial  software  used  to  create  the  JDT  displays  was  a  heavy  CPU  user 
under  this  load  condition.  This  problem  was  lessened  by  moving  the  display 
process  to  a  second  SUN  workstation.  Analysis  of  the  remaining  problems 
revealed  that  special  care  had  to  be  exercised  when  using  the  UNIX  socket 
feature  under  heavy  load  conditions.  This  feature  was  used  to  pass  data 
between  processes.  In  particular,  the  use  of  UNIX  sockets  for  passing  plot  data 
from  radar  inputs  to  tracking  had  to  be  redesigned  and  implemented  to  handle 
the  live  radar  load  conditions  experienced  at  RADC. 

One  other  major  problem  became  apparent  while  running  under  full  load  for 
prolonged  periods  of  time.  Eventually  the  number  of  tracks  processed  by  the 
system  began  to  drop,  gradually  falling  far  below  the  number  of  tracks  the 
system  was  designed  to  handle.  This  problem,  which  had  a  variety  of 
symptoms,  also  had  a  vanety  of  causes.  Basically  they  were  all  related  to  the 
scheme  for  re-using  track  numbers  and  track  slots,  which  are  returned  for  reuse 
by  a  tracker  after  a  track  is  dropped.  This  led  to  a  complicated  set  of  logic  which 
controls  re-establishing  these  track  numbers  and  storage  locations  for  use  by 
new  tracks.  After  extensive  analysis  and  testing  and  a  great  deal  of  support 
from  RADC  personnel,  this  logic  was  re-implemented  so  it  now  supports  the 
load  environment  required  for  the  JDT  system.  The  final  testing  was  completed 
in  late  January  1990. 


TABLE  3.0 


TAT  LIST  AND  SYNOPSIS 


aim 

aPfflBLJUtalE  1 

SYNOPSIS  _  _ 

TAT01 

Radar  Inputs 

Demonstrate  real  time  acceptance  of  data 
messages  from  10  JSS  radars  or  the  ADI 

Simulator  (if  available). 

TAT02 

Automatic  Track 
Generation 

Demonstrate  automatic  track  generation 
algorithms.  Maintain  tracks  using  an  (n)  hit  out  of 
(m)  scan  approach  for  all  potential  tracks  within 
reporting  range  of  radars. 

TAT03 

Track  Presentation 

Demonstrate  presentation  of  track  data  and 
individual  radar  reports  using  JSS  symbology. 
Coverage  of  all  ten  radars  will  be  shown. 

TAT04 

Track  Tell 

Demonstrate  capability  to  tell  tracks  to  a  concurrent 
internal  process  or  to  the  ADI  Simulator  (if 
available).  Three  modes  of  operation  will  be 
demonstrated:  tell  all  tracks;  tell  selected  tracks; 
and  stop  track  tell. 

TAT05 

Track  Correlation 

Demonstrate  acceptance  of  track  tell  input  from  a 
minimum  of  ten  trackers  and  production  of  a  master 
track  file. 

